In a typical wireless communication network, wireless devices, also known as wireless communication devices, mobile stations, stations (STA) and/or user equipments (UE), communicate via a Radio Access Network (RAN) to one or more core networks (CN). The RAN covers a geographical area which is divided into service areas or cells, with each service area or cell being served by a radio network node such as a radio access node e.g., a Wi-Fi access point or a radio base station (RBS), which in some networks may also be denoted, for example, a “NodeB” (NB) or “eNodeB” (eNB), “gNodeB” (gNB). A service area or cell is a geographical area where radio coverage is provided by the radio network node. The radio network node communicates over an air interface operating on radio frequencies with the wireless device within range of the radio network node.
A Universal Mobile Telecommunications System (UMTS) is a third generation (3G) telecommunication network, which evolved from the second generation (2G) Global System for Mobile Communications (GSM). The UMTS terrestrial radio access network (UTRAN) is essentially a RAN using wideband code division multiple access (WCDMA) and/or High Speed Packet Access (HSPA) for wireless devices. In a forum known as the Third Generation Partnership Project (3GPP), telecommunications suppliers propose and agree upon standards for third generation networks, and investigate enhanced data rate and radio capacity. In some RANs, e.g. as in UMTS, several radio network nodes may be connected, e.g., by landlines or microwave, to a controller node, such as a radio network controller (RNC) or a base station controller (BSC), which supervises and coordinates various activities of the plural radio network nodes connected thereto. This type of connection is sometimes referred to as a backhaul connection. The RNCs and BSCs are typically connected to one or more core networks.
Specifications for the Evolved Packet System (EPS), also called a Fourth Generation (4G) network, have been completed within the 3rd Generation Partnership Project (3GPP) and this work continues in the coming 3GPP releases, for example to specify a Fifth Generation (5G) network. The EPS comprises the Evolved Universal Terrestrial Radio Access Network (E-UTRAN), also known as the Long Term Evolution (LTE) radio access network, and the Evolved Packet Core (EPC), also known as System Architecture Evolution (SAE) core network. E-UTRAN/LTE is a variant of a 3GPP radio access network wherein the radio network nodes are directly connected to the EPC core network rather than to RNCs. In general, in E-UTRAN/LTE the functions of an RNC are distributed between the radio network nodes, e.g. eNodeBs in LTE, and the core network. As such, the RAN of an EPS has an essentially “flat” architecture comprising radio network nodes connected directly to one or more core networks, i.e. they are not connected to RNCs. To compensate for that, the E-UTRAN specification defines a direct interface between the radio network nodes, this interface being denoted the X2 interface. EPS is the Evolved 3GPP Packet Switched Domain. New radio (NR) is a new radio access technology being standardized in 3GPP.
FIG. 1 illustrates S1/EPS architecture based procedures required for establishing a connection of an idle wireless device also referred to as an idle-connected mode transition, and also for tearing down the connection when the wireless device has not been active for long time which may be referred to as a connected-idle mode transition. As can be seen there is a significant signaling overhead on the radio/Uu and S1AP interfaces. Thus, FIG. 1 shows LTE connection setup and tear down.
In 3GPP, work is ongoing, both in LTE and new radio (NR) also referred to as 5G, towards supporting lightly connected wireless devices referred to as wireless devices in an inactive state or mode, which can be considered as an intermediate state between idle and connected states, where the wireless device access stratum (AS) context is kept both at the wireless device and the RAN, where the wireless device may still be seen as if it is in connected state from the CN point of view and in idle state from the RAN point of view.
An advantage of operating in this inactive state is a reduced signaling towards the CN and faster transition to the connected state as compared to idle-connected state transitions, while maintaining the wireless device power saving advantages of idle state. It should be noted that the terms “inactive”, “suspended”, and “lightly connected” are used interchangeably throughout this document. It is for further study (FFS) in NR whether a wireless device's inactive to connected state transitions are hidden completely from the CN, from both Control Plane (CP) and User Plane (UP) perspectives. The discussion herein is mostly on the RAN aspects and thus applicable to both cases, i.e. CN is aware of the inactive/connected state transitions or the state transitions are transparent to the CN.
In LTE, when a decision is made by the network to move the wireless device to an inactive state, the radio network node sends to the wireless device an RRCConnectionRelease message with the release cause value of rrc-suspend and it is also provided with a Resume ID. The wireless device stores the resumeIdentity and the wireless device AS context, e.g. including the current Radio Resource Control (RRC) configuration, the current security context, the Packet Data Convergence Protocol (PDCP) state including Robust Header Compression (ROHC) state, Cell Radio Network Temporary Identifier (C-RNTI) used in the source Primary Cell (PCell), the cell identity and the physical cell identity of the source PCell. The wireless device further re-establishes all Radio Link Control (RLC) entities, both for Signal Radio Bearers (SRB) and Data Radio Bearers (DRB); and suspends all DRBs and SRBs except SRB0. The RRC connection suspend procedure is illustrated in FIG. 2. The wireless device is illustrated as a UE and the radio network node is illustrated as an eNB.                1. Due to some triggers, e.g. the expiry of a UE inactivity timer, the eNB decides to suspend the RRC connection.        2. The eNB initiates the S1-AP UE Context Suspend procedure to inform a Mobility Management Entity (MME) that an RRC connection is being suspended.        3. The MME requests a Serving-Gateway (S-GW) to release all S1-U bearers for the UE.        4. MME acknowledges the UE Context Suspend request in step 2 with a UE Context Suspend response.        5. The eNB suspends the RRC connection by sending an RRCConnectionRelease message with the releaseCause set to rrc-Suspend. The message includes the resumeIdentity which is stored by the UE.        6. The UE stores the AS context, suspends all SRBs and DRBs, and UE enters RRC_idle light connected state.        
When the UE later wants to resume the connection, e.g. in response to an UL data to be sent or to receive a paging request for DL data, the UE sends an RRCConnectionResumeRequest message with the saved resumeIdentity. The eNB responds with an RRCConnectionResume message, and both the UE and eNB restore the saved UE AS context, and data transmission/reception from/to the UE can be resumed. Note that the resume operation can be performed in an eNB other than the eNB that was serving the UE when the UE was suspended. In that case, the new eNB may perform a context fetch e.g. by using the Retrieve UE Context procedure from the old eNB since the resume identity includes information about the old eNB/cell.
The RRC connection resume procedure in the same eNB and new eNB are illustrated in FIG. 3 and FIG. 4, respectively.
FIG. 3 shows RRC connection resume procedure in the same eNB.
1. At some later point in time, e.g. when the UE is being paged or when new data arrives in an uplink buffer at the UE, the UE resumes the connection by sending an RRCConnectionResumeRequest to the eNB. The UE includes its resume ID, the establishment cause, and authentication token. The authentication token is calculated in the same way as the short medium access control-identity (MAC-I) used in RRC connection re-establishment and allows the eNB to verify the UE identity.
2. Provided that the Resume ID exists and the authentication token is successfully validated, the eNB responds with an RRCConnectionResume. The message includes the Next Hop Chaining Count (NCC) value which is required in order to re-establish the AS security.
3. The UE resumes all SRBs and DRBs and re-establishes the AS security. The UE is now in RRC connected state.
4. The UE responds with an RRCConnectionResumeComplete confirming that the RRC connection was resumed successfully.
5. The eNB initiates the S1-AP Context Resume procedure to notify the MME about the UE state change.
6. The MME requests the S-GW to activate the S1-U bearers for the UE.
7. MME acknowledges the S1-AP Context Resume request with a S1-AP Context Resume response.
FIG. 4 shows RRC connection resume procedure in the new eNB.
1. Same as step 1 in the intra eNB connection resumption (see FIG. 3).
2. The new eNB locates the old eNB using the Resume ID and retrieves the UE context by means of the X2-AP Retrieve UE Context procedure.
3. The old eNB responds with the UE context associated with the Resume ID.
4. Provided that the Resume ID exists and the authentication token is successfully validated, the new eNB responds with an RRCConnectionResume. The message may include the NCC value which is required in order to re-establish the AS security.
5. The UE resumes all SRBs and DRBs and re-establishes the AS security. The UE is now in RRC_connected.
6. The UE responds with an RRCConnectionResumeComplete confirming that the RRC connection was resumed successfully.
7. The new eNB initiates the S1-AP Path Switch procedure, transmitting a Path Switch request, to establish a S1 UE associated signalling connection to the serving MME and to request the MME to resume the UE context.
8. The MME requests the S-GW to activate the S1-U bearers for the UE and updates the downlink path, i.e. modifies bearers.
9. MME acknowledges the Path Switch request with a Path Switch request acknowledgement (ACK).
10. After the S1-AP Path Switch procedure the new eNB triggers release of the UE context at the old eNB by means of the X2-AP UE Context Release procedure.
A feature studied in NR that may be standardized in Rel-15 or in further releases is small UL data transmission in RRC_inactive state. Small UL data transmission in RRC_inactive state refers to a feature where a wireless device in RRC_inactive state can transmit small UL data without necessarily performing a full state transition to RRC_connected state.
If supported, the feature should be service-agnostic, catering different service requirements. The feature should work either with 4-step or 2-step Random Access Channel (RACH), it remains FFS whether and how the solution works in the case of a contention based transmission of the UL data, possibly considered if RAN1 Working Group (WG) would make such a mechanism available. For the sake of simplicity, 4-step RACH is assumed herein. FIG. 5 shows an example of a message flow for the small UL data transmission in RRC_inactive state. A high level signalling flow may work as follows:
1. A UE in RRC_inactive state sends a random access preamble such as a Physical Random Access Channel (PRACH) preamble.
2. The network responds with a Random Access Response (RAR).
3. The UE sends small UL data with message 3, it is FFS whether the message 3 is a RRCConnectionResumeRequest or a message in a Media Access Control (MAC) Control Element (CE), the message 3 may contain at least an AS context identifier (e.g. resumeID) to be used for contention resolution. This message may contain all necessary information to enable the network to move the wireless device to RRC_connected state or to enable the network to let the UE remain in RRC_inactive state. It could also provide information to enable the network to apply overload control and prioritisation, if needed. Some open issues have been identified:
a. It is FFS how the UL grant size is defined;
b. It is FFS which other information will be necessary to enable the network to move the UE to RRC_connected state or to enable the network to let the UE remain in RRC_inactive state such as Buffer Status Report (BSR);
c. It is FFS if a data threshold would be applied to trigger a separate procedure for data transmission as opposed to connection resume;
d. It is FFS whether the solution could fulfil the SA3 requirements and/or recommendation in terms of security only with the AS content identifier;
e. It is FFS which information could be provided with the message 3 to enable the network to apply overload control and prioritisation, if needed;
f. It is FFS what form of overload control/prioritisation might apply in the contention based case.
4. Triggered by message 3, the network may be able to move the wireless device to RRC_connected state via a DL RRC message 4 (e.g. RRCConnectionResume). The network should be also able to update the AS context with Message 4.
It should be noted that the wireless device may be able to send subsequent UL data transmission, at least after receiving message 4. It remains FFS whether the term “subsequent small data” covers only the case of infrequent transmissions or also frequent transmissions.
In NR there will be a transition from RRC_inactive state to RRC_connected state that will anyway be standardized and used for the case of large data. An RRC_connected wireless device may have an active AS context that is suspended when the network moves the wireless device to the RRC_inactive state. During the transition from RRC_connected state to RRC_inactive state, the wireless device may be provided with an AS context identifier, e.g. the resume ID, and the AS context is stored in a radio network node such as a gNB in NR. Using this AS context identifier, the AS context may be located and fetched to a new serving radio network node when the wireless device resumes its connection. If a solution for small data in RRC_inactive state is supported, the same wireless device AS context identifier and location mechanisms could be used as in the state transition so completely different mechanisms do not have to be defined. The solution for small data should be able to at least support an RLC Automatic Repeat Request (ARQ) mechanism, while it remains FFS how Hybrid Automatic Repeat Request (HARQ) retransmissions would be used, depending on RAN1 progress.
For some of the remaining aspects, two solutions, denoted as A and B, are considered. Within each of these solutions there are further open issues such as security aspects related to how the network makes sure the wireless device sending data is the correct wireless device, how the wireless device makes sure the network responding is the correct network, whether previously used security keys may be reused and under which scenarios. If feature is to be supported it should be a down-selection among solutions A or B, as described in 3GPP R2-1700672: “Report of 3GPP TSG RAN WG2 AdHoc on NR”. In solution A, data is transmitted with some control information without any RRC signalling involved while in Solution B data is multiplexed in the MAC level with an RRC message, possibly an RRCConnectionResumeRequest.
As discussed above, the reason for the introduction of the inactive state and RRC suspend/resume procedures is to reduce signalling, especially in the CN, and also faster transitions to connected state when the connection has to be resumed due to incoming DL data or upcoming UL transmission.
A problem being addressed herein is illustrated in FIG. 6. In FIG. 6, Tinactivity is the inactivity time for the wireless device, i.e. if Tinactivity have elapsed since there was any UL or DL data from/to that wireless device, the network will suspend the wireless device, i.e. transit the wireless device to a different state. TUL refers to the time it takes for a scheduling request to be transmitted from the wireless device to the radio network node such as a gNB. TDL is the time it takes for an RRCConnectionRelease message to be transmitted from the radio network node to the wireless device. TprocessingUE refers to the time it takes for the wireless device to process RRC messages, and TprocessinggNB is the time it takes the radio network node to process the received scheduling request from the wireless device. The inactivity time of the wireless device may expire at time X.
For the scenario shown in FIG. 6, if an UL data becomes ready to be sent at the wireless device any time before A=X-TUL-TprocessinggNB, for example, at the start of the dotted line in FIG. 6, then the wireless device's scheduling request would have arrived at the radio network node before the inactivity timer has expired, and as such the wireless device will not be put in inactive state. Instead, the wireless device will be provided a grant and be able to send the UL data.
If UL data becomes ready to be sent at the wireless device at any time after B=X+TDL+TprocessingUE, the wireless device would have already moved to inactive state, and thus it must go through the resume process as shown in FIG. 3 before it can send the UL data.
In the case where the UL data arrives at the wireless device during the time t wherein t is A<t<B, the wireless device will still end up receiving the suspend command because the scheduling request will not reach the radio network node before the suspend command was sent out to the wireless device. Thus, the behaviour will be the same as if the UL data has arrived after time B, i.e., the wireless device must request to be resumed and be able to send the data only after the radio network node has resumed it. This behaviour is very inefficient because it will result in the wireless device going to inactive state and immediately going back to connected state again, causing unnecessary signalling as well as increasing the UL latency. This will delay the transmission of data and thus reduce or limit the performance of the wireless communication network.